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CHAPTER ONE - 
Background 

I.A. WHY A GATEWAY 
PROTOTYPE? 

The National Aeronautics and Space 
Administration (NASA) Access 
Mechanism (NAM) was initiated to 
demonstrate the feasibility of using a 
graphical user interface (GUI) and 
intelligent gateway technology to 
streamline access to sources of Scientific 
and Technical Information (STI). 

The NAM project is based upon a 
technology known as the Intelligent 
Gateway Processor (IGP). The IGP 
concept was pioneered by Lawrence 
Livermore National Laboratories (LLNL) 
in 1983 in a joint effort sponsored by 
NASA, the Department of Energy (DOE), 
and the Department of Defense (DOD). 
They adopted a national bureau of 
standards project known then as the 
Network Access Machine. 

The purpose of the NAM prototype was to 
demonstrate to the NASA user community 
the concept of a system of this type is to 
streamline access to diverse sources of 
information in the NASA environment. To 
measure the applicability of the system, it 
was necessary to obtain feedback from 
selected users in various occupations. This 
was accomplished by fielding the system 
at user sites for a six-month testing period. 

The members of the NAM Development 
Team had experience with intelligent 
gateway and GUI technologies. The team 
brought the lessons learned from their 
previous experiences to NASA. The first 
step was to evaluate the strengths and 
weaknesses of the previous 
implementations and to make decisions 
about what would and would not meet the 
NASA requirements. 


LB. PROJECT HISTORY 
I.B.1. NASA SIT Program Overview 

The NASA Scientific and Technical 
Information (STI) Program was 
established as a result of the National 
Aeronautics and Space Act of 1958 to 
identify world-wide sources of scientific, 
technical, engineering, and related 
information; develop required policy 
statements; facilitate authorized access; 
and manage delivery of the information to 
NASA and its customer base. STI is basic 
and applied research results from the 
efforts of scientists and engineers. It 
includes new theory and information 
obtained from experimentation, 
observations, instrumentation, or 
computation in the form of text, numeric 
data, or images. STI may be further 
transformed, described, evaluated, and/or 
synthesized and recorded in print, digital, 
magnetic, or other media to enhance its 
communications and its usefulness and 
value to a wide spectrum of users and 
uses. 

From a historical perspective, NASA was 
a leader in acquiring and processing STI in 
the mid 1960s to the late 1970s. The user 
requirements and the services and products 
provided by the Program were in harmony. 
The REmote CONsole (RECON) retrieval 
engine was the first of its kind to provide 
users access to NASA’s bibliographic 
database system. In fact, RECON was a 
model for commercial companies and 
other Federal agencies. From the late 
1970s to 1990, the NASA user 
requirements became unknown and 
NASA’s operation remained unchanged 
while other Federal organizations moved 
ahead. In 1990, NASA was still using the 
system that was developed in the 1960s 
with few changes. Beginning in 1990, new 
management began to implement Total 
Quality Management (TQM) 
methodologies to improve the current 
operations while planning to modernize 
the fragile Program. One of the projects 
initiated during this period was the NAM 
effort. 
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A strategic vision document prepared by 
the Program stated, "the focus of our effort 
will be the development of a global 
program to encourage the creation and 
exchange of STI and facilitate its use." To 
implement this effort the Program needed 
to know the following: 

• The information requirements for the 
R&D community 

• The relevant information sources to 
meet those requirements 

• Ways of facilitating access to those 
information sources 

A team comprised of multiple contractors 
was formed. Curtis Generous of UUcom is 
the Senior Technical Manager responsible 
for the technical design and overall 
management of the project. Rick Dunbar 
of UUcom is the Senior Analyst 
responsible for programming and porting 
the code to other platforms. Denise 
Duncan from Logistics Management Inc. 
(LMI) is the Information Specialist 
responsible for performing user studies, 
identifying sources of information, and 
interfacing and coordinating with users. 
Due Tran, under contract to UUcom, is an 
expert in the use of X.l 1 OSF/Motif and is 
responsible for the initial design and 
programming the GUI. John Lycas (LMI) 
is the Information Specialist responsible 
for initial design and researching X 
servers on PCs. Ardeth Taber-Dudas and 
Lisa Burdick (both of RMS Associates) 
are responsible for creating the online help 
screens and the NAM User Manual and 
providing overall support. 

Judy Hunter, as the Manager of Special 
Projects for NASA, is responsible for the 
overall government management of the 
project. 

I.B.2. User Requirements 

In 1990, the NASA STI Program 
conducted a study to evaluate the 
feasibility of using the IGP and GUI 
technology to meet the NASA users' 
requirements for access to online 


information. The NASA user community 
consists of NASA researchers, engineers, 
librarians, managers, and the broader 
university and aerospace industry 
communities. 

The primary objective of the study was to 
assess the potential for an intelligent 
gateway to meet NASA users’ 
requirements for online STI retrieval. The 
study was limited to a sample of the user 
community and included NASA's Ames 
Research Center (ARC), Langley Research 
Center (LaRC), Lewis Research Center 
(LeRC), and Goddard Space Flight Center 
(GSFC). 

After the results of the study were 
gathered and examined, the NAM project 
scope changed; the prototype's design was 
expanded to include internal databases to 
NASA such as RECON, as well as 
external databases such as STN and WAIS 
sources. In addition, the prototype design 
was changed to include peer locating tools. 
This feature was added in response to the 
users' expressed need, identified during 
study interviews. 

The Program knew that users needed a 
simple way to locate and access STI from 
their offices. They learned that users were 
using a variety of methods to do this: 
chatting with coworkers in their group, 
calling or writing colleagues for referrals 
to other experts or for information, going 
to the library or calling the librarians, and, 
infrequently, directly accessing 
information sources from their desktops. 
Their information and support 
requirements are described in the NASA 
Gateway Requirements Analysis (NASA 
TM-104951) published in March, 1991. 
This document summarizes the 
alternatives and recommended actions, 
conclusions, and findings resulting from 
the study. 

There was a high degree of consistency in 
the user responses regarding the functional 
requirements of an improved STI delivery 
system. The requirements of the majority 
of interviewees can be grouped in three 
parts: 
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1. Broader And Deeper Coverage Of 
Relevant Disciplines. Users expressed a 
need for comprehensive coverage of the 
disciplines in which NASA performs basic 
and applied research. This includes 
improved subject coverage of engineering, 
physics, geology, mathematics, electronics 
and control systems, materials, U.S. and 
international patents, and life sciences. 

2. Improved Identification of 
Information Sources. Users indicated that 
they need assistance identifying and 
retrieving pertinent STI from all major 
foreign sources, and accessing numerical 
data sets that result from previous 
observation-based research. At a 
minimum, they need assistance in locating 
STI sources within NASA, the U.S., and 
internationally, even where gateway 
access is not feasible. 

3. Improved Access to Information 
Sources. Users specified the need for 
reliable telecommunications off-Center; 
for example, simplified electronic mail 
across varying mail systems and networks 
and increased information about, and 
access to, resources. They also need access 
to some Center library services from their 
offices. They need to execute simple STI 
queries from their desktop systems. These 
queries include querying by parameters 
other than text— for example, by chemical 
structure— and retrieving complete 
documents with graphics intact, browsing 
STI sources and querying results, and 
forwarding retrieved foreign materials to a 
translation service. They should be able to 
set up queries for automatic execution on a 
daily, weekly, or as needed basis to keep 
aware of specific topics. 

The requirements report recommended six 
actions: 

1. That the STI Program provide a 
prototype intelligent gateway 
for user testing for a minimum 


of six months to allow users to 
evaluate the utility of access to 
new STI sources. 

2. That the prototype designers 
select a limited set of STI 
sources representing the variety 
of available on-line STI and 
having the highest relevancy to 
the prototype user community. 
These were to include a source 
of information on research 
performed outside the U.S.; 
sources of chemistry, materials, 
physics, engineering and patent 
information; resources; and 
access to human resources, 
such as the larger research 
community and the STI 
Program staff. 

3. That the prototype include the 
applications most frequently 
requested by users, and that it 
have a two-level interface: one 
level for end-users and one for 
library staff. 

4. That the prototype be based in 
Center libraries and selected 
end-user offices. 

5. That the prototype use existing 
networks to provide simplified, 
reliable telecommunications 
paths connecting user 
workstations, the prototype 
host, and the remote 
information sources. 

6. That all organizations that 
participate in STI delivery and 
use be included in the 
prototype. 

A listing of user requirements is shown in 
Table 1, with comments on how the 
prototype addressed these requirements. 
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Table 1. Summary of Prototype Responses to Requirements 

* A indicates Alpha prototype version and B indicates Beta prototype version 


Design of the NAM, which began in the 
fall of 1991, was based on users’ 
requirements stated in the NASA Gateway 
Requirements Analysis document. Other 
factors that could have an impact on the 
ability to use rapid prototyping 
methodologies were also employed. The 
initial plan was to have a working 
prototype for testing within a year. 

A working version of the prototype was 
first demonstrated in April 1992 at the 
NASA STI Managers' Conference. 


I.B.3. Conceptual Design 

In the summer of 1992, the STI Program 
assembled a team to respond to the 
recommendations stated in the 
requirements report. The team operated 
under two major constraints: a working 
prototype was needed within one year, and 
the budget for hardware, software, and 
personnel was limited. 
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The concept for the NAM was a unique 
approach to STI assistance: a desktop tool 
to assist scientists, engineers, and 
information specialists in locating and 
using a complex mix of resources. These 
resources included formal and informal 
sources of information for many 
disciplines, Internet resources, and 
channels of communication with fellow 
scientists and engineers and information 
professionals. In essence, this system 
represented an expansion of the definition 
of STI to include Internet resources and 
human beings. 

In addition to this wider variety of 
resources, the NAM concept included a 
higher degree of integration than was 
heretofore seen in STI systems. This 
desktop tool had to support (as much as 
feasible) all the ways users find, get, and 
use STI, so they would only have to install 
and use one STI tool. It had to be 
integrated into the user's desktop 
environment, so it would be natural to 
incorporate its use into the normal work 
patterns. It had to be easy to use (less than 
a half-day of training) for the beginner, 
and not constraining to the experienced 
user. For both integration into the desktop 
environment (which was primarily that of 
a UNIX workstation, Macintosh, or 
personal computer) and ease of use, a 
graphical user interface was desirable. 

With this concept in mind, the team 
evaluated software available from other 
agencies and commercial off-the-shelf 
(COTS) software in terms of its potential 
for the NAM prototype implementation. 
Some of these systems are listed below, 
with a summary of the reasons each was 
not used in the NAM: 

Intelligent Gateway Processor (IGP) 
Software from Lawrence Livermore 
National Laboratories (LLNL) 

The original IGP technology was 
developed by LLNL under contract to 
NASA, DOD, and DOE. The NAM team 
obtained a copy of this software from 
LLNL and found it too inflexible, both for 
the initial modifications to create the NAM 
prototype and those needed in response to 


the prototype evaluation. The user 
interface was limited to terminal 
emulation, and in general, the software 
was not modular enough. 

Defense Gateway Information System 
(DGIS) from the Defense Technical 
Information Center (DTIC) 

DTIC was one of the sponsors of the 
original IGP development at LLNL. DTIC 
continued development of the software in 
the DGIS in the 1980s. It had many of the 
same limitations as the IGP software-a 
centralized architecture, with users 
connecting to the host minicomputer via a 
VT100 terminal emulation; no Application 
Programming Interface (API); and thus no 
potential for a GUI. In general, the 
software would not port well to a 
distributed computing environment. 

Foreign Market Analysis System 
(FMAS) prototype developed by the 
Army Materiel Command (AMC) 

FMAS was developed based on the DGIS 
software and had all the limitations of the 
DGIS software. However, in the VT100 
screens, a query form had been used. This 
type of query preparation screen had been 
used successfully by engineers at the U.S. 
Army Laboratories. 

The commercial software packages 
reviewed included Ascent Gateway, 
STILAS, and Grateful Med. 

Control Data Corporation’s Ascent 
Gateway software is a commercial version 
of the DGIS system. It includes database 
access and query capability, electronic 
mail, and internal peer location 
mechanisms. It lacks a GUI and a 
distributed architecture. 

SIRSI Corporation's STILAS software 
offered multi-database searches, but no 
tools for access to 'informal' data sources, 
such as peers and bulletin boards. It would 
have required a great deal of modification 
to provide Internet tools and a GUI. Since 
all modifications to the software had to be 
performed by SIRSI corporation, it was 
not flexible enough for prototype 
development. 
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Grateful Med is the National Library of 
Medicine's (NLM) front end to their 
Medline database. It consists of a software 
package that allows asynchronous 
communications between a Macintosh 
computer and the host database machine. 
This package was inflexible and unable to 
support other communications capabilities 
(i.e., TCP/IP), was supported only on the 
Macintosh, and did not support other 
databases. 

After reviewing the feasibility of using 
existing intelligent gateway software, 
NASA decided to develop a prototype 
based on the newer LLNL source code. 
After a study of the program, it was 
determined that too many changes and 
modifications were required to import the 
functions needed to meet the NASA STI 


community’s requirements. The prototype 
development was designed, implemented, 
and coded with the understanding that this 
was a throwaway system that was to be 
used solely as a rapid prototype for the 
purpose of demonstrating the concept to 
the NASA user community. During the 
Beta test phase, constant monitoring of the 
usage of the prototype and ongoing 
communication with testers allowed for 
the design to be refined. This resulted in a 
total of three prototype versions being 
released, each with features and fixes 
requested by the test community. 

A number of design considerations and 
practical constraints determined the 
development environment and the scope of 
the prototype. 
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CHAPTER TWO - 
Prototype 

II.A. SYSTEM DESIGN 

CONSIDERATIONS 

ILA.1. Hardware Factors 

The hardware requirements for the NAM 

prototype were as follows: 

• That it be well-suited for development. 
The design team wanted assurance that 
hardware factors would not impair the 
software development process. This 
meant finding an industry standard 
hardware platform for which tools and 
software could easily be obtained from 
third party vendors. 

• That it support the networking and 
communications capabilities needed 
for NAM. At the time of the original 
design, many networking protocols 


were considered. These included 
TCP/IP, OSI, DECNET, and 
AppleTalk. The platform had to 
support all of the above protocols, 
either as a standard part of the 
operating system or through add-on 
hardware/software. 

• That it support the GUI interfaces 
proposed to be used by NAM. This 
meant that color bitmap screens had to 
be supported by the hardware. 

• That the development team have some 
knowledge of the hardware 
environment. This requirement was 
key to implementing the prototype 
within a year. 

• That it serve as a multi-purpose 
computing platform. The machine also 
had to provide local services such as 
email and basic wide area network 
services such as routing and domain 
name support to the local area network 
shown in Figure 1 . 



Figure 1. STI Program LAN 
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II.A.2. Operating System Factors 

Additionally, the prototype specification 

contained requirements that needed to be 

supported by the operating system: 

• Multi-tasking. The NAM prototype 
server would be supporting many 
simultaneous users concurrently. 

• OS support of networking facilities. 
The networking capabilities of the 
hardware needed to be supported as 
an integral part of the system. The 
design team's experience with the 
socket level abstraction provided by 
many OSs strengthened this 
requirement. 

• Process control capabilities. The 
distributed client/server design 
approach required that the OS include 
background processing, process 
control, and violation protection. 

• User access control. Because the 
NAM server supports simultaneous 
users, the OS facilities should support 
the concept of user identification and 
provide facilities for authentication 
and authorization. This would give the 
NAM server the capability of 
accessing and granting permissions to 
individual users, and groups of users, 
and source or target host 
identification. 

• Must comply with FIPS requirements 
to meet all POSIX specifications, 
including PI 003.1. 

After reviewing all of these above 
requirements, die UNIX- based operating 
system (or a variant of) was chosen as the 
operating system of choice. 

II.A.3. Graphical Interface Factors 

It was also necessary to decide what 
windowing environments the graphical 
user interface (GUI) would support. The 


NAM development team had several 
options available to them at this time: 

• Sunview/XView 

Sunview was immediately rejected due 
to it's proprietary nature and the fact 
that the vendor (SUN Microsystems) 
had announced plans to drop support in 
the near future. 

• Mac OS 

The prototype developers had the 
option of developing a GUI for the 
Macintosh Operating System 
(MacOS); however, the intended 
audience for the prototype included 
other than Macintosh users and this 
option was restrictive. 

• Microsoft Windows 

MS Windows was by far the most 
popular platform among the intended 
users. The lack of standardization in 
development tools and 
communications API's caused 
concerns on the support of such a 
platform. 

• The choice of MIT/X 1 1 Revision 4 
Windowing System, was made for 
several reasons: 

It was standards based, as the X 
protocol was an accepted standard 
in FIPS PUB 158-1 (IEEE 
P1295.1) 

It was a widely used environment 
in the NASA scientific and 
engineering community. 

It was freely available in the public 
domain with full source code and was a 
de-facto standard on most workstations 
such as SUN and Silicon Graphic. 

DOS, Microsoft Windows, and MacOS 
users could be supported by purchasing a 
commercial X server for their 
workstations. All users would be able to 
use the GUI from their own desktop 
computer. 
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II.A.4. Development Tools Factors 

To facilitate the development effort, it was 
agreed that the following guidelines 
should be considered in the selection of an 
acceptable environment: 

• Support industry standard high level 
language compilers, such as Pascal, or 
ANSI-C. 

• Support standardized Application 
Programming Interfaces (API) 
whenever possible to support all of the 
low level routines. 

• Install tools and facilities to support 
development in a multi-platform, 
distributed environment. Since the 
development would be done by several 
people working on different sections of 
the application at one time, the ability 
to support such a work group was 
necessary. 

• Have available proper debugging tools 
and utilities to support a multiple 
developer environment; such tools 
include revision control utilities, 
linker, preprocessors and incremental 
loaders. 

• Support the Graphical User Interface 
(GUI) environment that would be 
selected (see Chapter II.A.4 above). 

After careful review of all the available 
options, and in view of all of the factors 
and considerations outlined above, the 
selection of a SUN SPARC was made. The 
final architecture of the prototype test bed 
consisted of a SUN 4/470 SPARC server, 
chosen as the hardware platform for 
development because it has a robust 
Operating System (SunOS) and a contract 
was already in place that would allow the 
procurement period to be relatively short. 
Two SUN SPARC IPC workstations were 
also purchased to be used for 
development. 

Since a UNIX-based development 
environment was chosen, a rich set of tools 


was made available for creating the 
prototype. A compiler for the C 
programming language is provided with 
the operating system and is the language 
of choice of the developers. Many public 
domain utilities and tools were also used 
during the development phase of this 
project, including such facilities as the 
following: 

Perl: an interpreted language optimized 
for scanning arbitrary text files, extracting 
information from those text files, and 
printing reports based on that information. 
It's also a good language for many system 
management tasks. The language is 
intended to be practical (easy to use, 
efficient, complete) rather than beautiful 
(tiny, elegant, minimal). It combines some 
of the best features of C, sed, awk, and sh, 
so people familiar with those languages 
should have little difficulty with it. 
(Language historians will also note some 
vestiges of csh, Pascal, and even BASIC- 
PLUS.) Expression syntax corresponds 
quite closely to C expression syntax. 
Unlike most UNIX utilities, Perl does not 
arbitrarily limit the size of your data-if 
you've got the memory, Perl can slurp in 
your whole file as a single string. 
Recursion is of unlimited depth. And the 
hash tables used by associative arrays 
grow as necessary to prevent degraded 
performance. Perl uses sophisticated 
pattern matching techniques to scan large 
amounts of data very quickly. Although 
optimized for scanning text, Perl can also 
deal with binary data and can make dbm 
files look like associative arrays (where 
dbm is available). 

Xups : a graphical source level debugger 
for the C programming language running 
under the XI 1 and Sun View window 
systems. It supports both run time 
debugging with breakpoints and post- 
mortem debugging from a core file. On 
Suns you can attach ups to a running 
process. Xups runs in its own window, 
thus not interfering with the target 
program’s I/O. The Xups window has two 
major areas - one showing a structured 
document representing the target state, the 
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other showing the source that is being 
executed. 

Zmail : zmail is a MIME-compliant mail 
user agent (MU A) that can support one of 
several mail transport agents (MTAs). In 
its typical configuration, zmail supports 
SMTP. Zmail supports two interfaces: an 
X/Motif graphical user interface, and a 
command line interface. 

II.A.5. XWindow Development Toolkit 
Considerations 

Once the selection of an appropriate 
windowing system was made, the selection 
of an appropriate toolkit to support the 
"look and feel" that was desired for the 
prototype was needed. The options 
available to the team at the time consisted 
of : 

Xlib 

Xlib was eliminated immediately due to 
the very complex nature of this low-level 
library, and due to the enormous amount 
of work necessary to develop original 
widgets to standardize the look of various 
forms. 

Andrew Toolkit 

The Andrew Toolkit was eliminated next 
because of poor developer support and 
limited functionality. The Andrew toolkit 
is a public domain toolkit that was one of 
the first developed for XI 1 programmers. 

OpenLook (OLIT) Toolkit vs. 
OSF/Motif 

The Open Look toolkit versus OSF/Motif 
were then the only two choices left. After 
conducting an informal market survey of 
software firms and agencies doing their 
own XI 1 developments, we found an 
approximate 3: 1 ratio of Motif-based 
applications over OLIT. The development 
team chose the OSF/Motif toolkit because 
it was more widely implemented and this 
increased the probability of incorporating 
the NAM gateway with other XI 1 systems 
in the future. OSF/Motif is also based on 
Xlib which would provide a simpler 
development environment and a more 
pleasing look and feel. The development 


staff also had previous experience in 
developing applications with OSF/Motif. 

II.A.6. Networking Considerations 

The STI user community is geographically 
dispersed and therefore presented some 
constraints on the communications 
alternatives that were available. The NAM 
development team had several wide area 
network alternatives to choose from: 

NASA Wide Area Connectivity 

NASA's current wide area connectivity 
includes TCP/IP and DECNET wide area 
networks provided by the NASA Science 
Internet (NSI) and the Program Support 
Computer Networks Internet (PSCNI). 
Both the NSI and PSCNI provide 
connectivity between NASA Centers. The 
PSCNI does not, in general, provide 
connectivity to the Internet. The NSI is a 
more open network that is designed to 
facilitate communications with NASA 
researchers globally, and as a result 
provide good Internet connectivity for 
NASA researches. Our goal was to support 
the entire NASA research community so 
we chose the NSI as our wide area 
network provider. 

GOSIP 

In addition, there was the need to support 
GOSIP (Government OSI Profile) winch 
mandates the use of Open Systems 
Interconnection (OSI) networking 
protocols where feasible. There is 
currently very little OSI support and few 
OSI products available. 

Due to the lack of wide area OSI support 
and products, we chose to use the TCP/IP 
networking protocol suite due to it's 
extensive availability and reliability. 
Furthermore, since TCP/IP was on the 
NASA Inter Center Council on 
Networking's (ICCN) list of Approved 
Short Term Protocols, this would not 
violate the ICCN mandate during the 
migrating to OSI. (ICCN is the NASA 
Council responsible for implementing OSI 
in the NASA community). The 
development staff also had extensive 
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background in the development of TCP/IP 
based services, and were especially 
familiar with the socket level abstraction 
that is provided by most UNIX based 
platforms. Sockets are an endpoint for 
communication between processes, similar 
to the way a telephone is the endpoint of 
communication between humans. Each 
socket has queues for sending and 
receiving data. Sockets are typed 
according to their communications 
properties. These properties include 
whether messages sent and received at a 
socket require the name of the partner, 
whether communication is reliable, the 
format used in naming message recipients, 
etc. 

Communications 

To support a truly distributed application, 
it is imperative that packet level 
connectivity exists between each module 
in the NAM application group. The lack of 
such packet level connectivity can be 
resolved through the use of several 
alternative connectivity tools including: 

Asynchronous Communications 

There was also a need to support 
asynchronous communications such as dial 
up access for users who did not have 
Internet connectivity. This option 
presented bandwidth limitations. There are 
a number of ways to support both IP and 
the X Window System over asynchronous 
dial-up lines including Serial Line IP 
(SLIP), which is a widely implemented but 
non-standardized protocol, and the Point - 
to-Point Protocol (PPP). PPP has been 
described and accepted as a standard and 
offers many built-in features which make 
the configuration and management of a 
PPP connection much easier. Performance 
of a PPP connection is also supposedly 
higher due to various techniques built-in to 
the protocol such as Header compression. 
Type of Service (TOS) prioritizing, 
automatic IP addressing negotiation, and 
others. 

In general, we decided not to support dial- 
up access for our test community. We did, 
however, use asynchronous 
communications for demonstrations at 


conferences and at other government 
agencies. 

X Protocol over Serial Line 

For those platforms (e.g. Sun’s, Hp’s) 
which use the X-Windowing system as the 
GUI, the use of a specialized X transport 
protocol over serial lines is also an 
alternative. There are three known 
implementations of this capability, two 
proprietary and one an in-process standard. 

• X-Remote - NEC’s proprietary 
implementation of a stripped down X 
protocol which essentially allows X to 
run over a non-IP stack. By 
eliminating the TCP/IP protocol 
overhead and through the use of 
compressing and tokenizing 
techniques, NEC has been able to 
obtain fairly good benchmarks. Field 
tests of this technique showed 
acceptable levels of performance when 
used in conjunction with V.32bis 
modems (14.4 Kbaud modems). The 
display of large graphic images, such 
as those used in the weather maps on 
the NAM system, proved to be too 
slow for acceptable use. Although a 
proprietaiy protocol, NEC has released 
the details of the protocol to the X 
Consortium which is in the process of 
making the X-remote a baseline 
release for the Low Bandwidth X 
(LBX) protocol in the future release of 
the XI 1 Release 6 Windowing system 
(see LBX below). 

• X-Express - Another competing 
technology attempting to duplicate 
NEC’s proprietary implementation. 

This protocol was not tested during the 
Beta test phase since as it became 
commercially available only during the 
last few days of the testing period. This 
approach is also a proprietary 
technique: there are no plans on 
making the protocol publicly available. 

• Low Bandwidth X (LBX) - NEC’s 
proprietary implementation of a 
stripped down X protocol has been 
released to the X Consortium who is in 
the process of making a slightly 
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modified version of X-remote as the 
Low Bandwidth X (LBX) protocol in 
the future release of the XI 1 Release 6 
Windowing system. Once this process 
is done (late 1993/early 1994), the 
definition of LBX will be finalized and 
published as a standard. No hard data 
about performance and platform 
support is yet available to the authors. 

II.A.7. Z39.50 and POSIX 

At the time of the prototype design, the 
specification for the 1992 version of the 
ANSI Z39.50 protocol had not yet been 
finalized. Furthermore, the handling of 
non-Z39.50 compliant queries needed to 
be achieved to handle some of the unusual 
characteristics of some of the remote data 
sources being used, and these types of 
queries did not fit well into the Z39.50- 
1988 spec. As a result, Z39.50 was not 
used in the prototype. 

POSIX 1003.1 is the IEEE Portable 
Operating System Interface for Computer 
Environments. Its goal is to provide a 
comprehensive operating system 
environment that application programmers 
can be confident will be supported across a 
variety of machines. The IEEE 1003.1- 
1990 national standard was adopted in 
April 1933 as FIPS PUB 151-2 POSIX. 1. 
POSIX- 1 provides a low-level kernel 
operations API to support such tasks as 
process control, signals, file management, 
etc. At the time of the start of development 
of the NAM prototype, neither the C 
compiler nor the interface builder and 
Motif toolkit supported the POSIX. 1 and 
ANSI-C standards needed to perform 
POSIX. 1 compliant development. For this 
reason, it was decided to not use the 
POSIX. 1 API. 

II.B. ALPHA DESIGN AND 
IMPLEMENTATION 

II.B.l. Time Constraints 

Development was started on the Alpha 
System in December of 1991. The 
scheduled release of the alpha was June 


1992. In February of 1992 the release date 
was changed from June to April so that a 
presentation and demo could be made at 
the annual STI Managers Conference to be 
held in Houston at the Johnson Space 
Center. This change in plans finalized 
what would be in the prototype. The demo 
also brought forth the need for a SLIP 
connection for asynchronous 
communications. 

Due to time constraints, many originally 
planned capabilities of the alpha system 
had to be cut, including the following: 

• Simultaneous searches of various 
remote databases 

• Canned queries and batch processing 
which would allow users to set up a 
"current awareness" system for 
themselves 

• The number of remote systems which 
would be queried 

• Accounting features to track cost and 
usage information 

• Non textual queries 

II.B.2. Technical Design 

The alpha prototype builds on the previous 
work of many other people; many of its 
facilities are based on ideas and functions 
from other projects and are presented in an 
intuitive, easy-to-use system. For example, 
query-by-forms interfaces have been used 
in both structured and unstructured 
databases. In addition, the Internet tools 
provided under the Bulletin Boards and 
Utilities icons were developed by others in 
the Internet community. 

The distributed nature of the NAM 
prototype was implemented using peer to 
peer inter-process communications 
techniques. There are several reasons for 
this modular design: 

• By distributing portions of the 
application to different processors, a 
certain amount of replication can be 
provided to improve reliability of 
service. 


12 



• Improved performance by distributing 
portions of the application to avoid 
slow network links or bottlenecks that 
may exist. 

• Improved performance by dedicating 
machines to be associated with specific 
tasks, such as database machines, 
where system load problems might 
exist. 

• Customization for a group or an 
individual is possible since the 
functionality of each module is clearly 
defined and limited in scope. By using 
the Application Programming 
Interfaces (API), a site can easily 
customize the NAM interface to 
provide specific capabilities needed for 
their users. 

• Supports geographically dispersed 
users and data collections. 

The NAM prototype had several false 
starts as the programming staff 
investigated the use of GUI development 
tools such as NASA’s TAE+, Integrated 
Computer Solution’s Xcessory-Builder, 
and X-Designer. None of those tools fit the 


requirements of the prototype (limited 
capability, cost, availability to use 
OSF/Motif, etc..). 

A diagram of the NAM architecture design 
is depicted in Figure 2. Each module of the 
NAM is self-contained, capable of 
communicating with the other modules via 
a strict transaction protocol, using TCP/IP 
as the underlying transport mechanism to 
assure a reliable, bi-directional 
communications path. The various 
network capable interfaces among 
modules are shown in dotted lines, while 
other interfaces which are internal paths, 
are shown in solid lines. The 
communication path among components is 
provided using TCP/IP-based inter-process 
communications. This allows all the 
modules to be running on the same 
machine or distributed among machines 
connected via local and wide area 
networks. Connectivity between the 
NASA Centers was provided by the 
NASA Science Internet (NSI), which, in 
turn, is connected to the rest of the 
Internet. The NAM prototype was 
designed to make use of this connectivity 
to operate. 



Figure 2. NAM Modules 
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Support to a limited number of users of 
dial-up communications has been provided 
using personal computers with Microsoft 
Windows, XVision and XRemote 
software, and high-speed modems for use 
at exhibits and demonstrations. 

II.B.3. NAM Modules 

The NAM is composed of nine basic 
modules: 

• Graphical User Interface (GUI) 

• Intelligent Source Locator 

• Database of Databases 

• NAM Server 

• Communications Toolkit 

• Communications Agents 

• Data Filters 

• Utilities and Bulletin boards 

• Peer Locator Tools 

The modules listed above are grouped into 
several programs that were developed on a 
Sun SPARC running SunOS 4.1.x. The 
Graphical User Interface (GUI) consists of 
two X-window clients that are executed 
and interact with the user. They are xnam 
and xconnect. The second program, ingd, 
is the information server for the Database 
of Databases and for the digital 
Phonebook. The last program, namd, is the 
NAM server which provides the 
connectivity to and talks to the remote 
databases on behalf of the user. These 
programs communicate with each other 
over a network. 

The NAM Server, Communications 
Toolkit, Communications Agents, and 
Data Filters are written in Perl. The rest of 
the modules are written in the C 
programming language (K&R). The GUI 
is based on XI 1 Release 4 using the 
OSF/Motif 1 . 1 toolkit and is currently 
being ported to XI 1 Release 5 and the 
OSF/Motif 1.2.2 toolkit. We are currently 
porting the code to IBM RS6000 and 
Silicon Graphics platforms. 

The NAM GUI is a custom built 
windowing application, tailored to the 
requirements of the STI Program user 
community. Use of standards compliant 


software (The X Window System) for the 
client ensures that the application will be 
portable to the variety of platforms found 
in the user community. Use of the 
OSF/Motif Toolkit provides a unified look 
and feel on all platforms (UNIX 
workstations, Microsoft Windows-based 
personal computers, and Macintosh 
systems). 

The prototype was developed in a 
distributed, multi-vendor environment, 
with the use of standards emphasized to 
maximize the potential for migration to 
other platforms in future versions. The 
GUI was implemented as a single X 1 1 
client called xnam . 

Xnam displays the top level icons to the 
user and responds to his requests. This 
program uses fork() and exec() to invoke 
any of the programs found under the 
email. Bulletin Boards, and Utilities icons. 
All of these programs are stand-alone 
applications that have been integrated into 
NAM for ease of use. 

To use the NAM, one's desktop computer 
must be able to display an X-window. 
DOS-Based and Macintosh computers 
must have an X-Window manager 
installed for this to happen. The NAM 
developers did an informal study of 
existing Xserver software based on 
reliability, speed, and ease of installation 
and maintenance and chose several for use 
with the NAM GUI. The software 
products chosen are listed in Table 2 
below. 


Hardware 


X Window 
Managers 


Xll Server 


IBM PC 
Clones 


DOS with 
MS- 

Windows 


Vision Ware, 
eXceed 


R5 


Macintosh 


MacOS 


MacX, eXodus 


R4 


Sun SPARC 


SunOS 
4. LX 


mwm,twm,ctwm, 

olwm,tvtwm 


R4, R5 


IBM 

RS6000 


AEX 


mwm 


R4 


Silicon 

Graphics 


IRIX 


4DWM 


R4 


Table 2. Xll Servers 
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The user’s computer must be connected to 
a TCP/IP network which can access the 
Internet or use an asynchronous protr ?ol 
for XI 1 over serial lines such as XRemote 
or LBX. 

The Intelligent Source Locator 

The intelligent source locator was 
implemented under the Data Sources icon 
in the GUI. The locator was implemented 
to allow users to query on a subject 
without knowing which formal source 
contained the information. The locator 
provides the following services: 

• Provide a list of databases 

• Provide a list of subjects 

• Locate appropriate sources on the 
known subjects. 


The Database Of Databases 

The Database of Databases is the database 
that contains the information about the 
formal data sources that NAM provides 
access to. In addition, the data used by the 
NASA phone book under the Peer Locator 
Icon is maintained under the same 
database management system. The 
databases and their subject coverage is 
manually maintained by the developers. 

The server’s database contains the 
Database of Databases, the digital NASA 
phone book, subject lists, connections 
data, and costing data. The Database of 
Databases maintains the records of remote 
sources, their subject coverage, and 
relevance scores for each subject. 

Xconnect is launched when a user requests 
to connect to a database. This program 
manages all of the query-by-forms screens, 
communicates with the NAM server, and 
controls the display of output from the 
communications toolkit. The internal 
routines extract relevant information from 
the form, generate a valid query syntax for 
the remote host, and then ships that query 
out. Currently, the query strings are built 
on the server in Crystal City, VA and then 
sent to the remote database. A historical 
track of all queries is kept and is viewable 


by the user to allow him to review a 
particular search strategy. 

The NAM Server 

The NAM server is a concurrent process 
that spawns a copy of itself for connection 
so that a large number of users may access 
it at any given time. The server provides 
user authentication and authorization, and 
also logs all activity. The NAM server 
incorporates the following: 

• Communications Toolkit 

• Communication Agents 

• Data Filters 

Communications Toolkit 

The Communications Toolkit provides a 
modular approach to providing 
communications capability to information 
retrieval systems external to the NAM. 

This facilitates modification of the user 
interface in response to user testing, while 
not affecting the server code. Another 
module provides batch and delayed 
operations. That spawns the appropriate 
agent and accepts commands from the 
remote user. 

The Communications Agents 
The Communications Agents are PERL 
scripts spawned by the Communications 
Toolkit that connect and communicate 
with the remote database on behalf of the 
user. 

The Data Filters 

The Data Filters provide reformatting 
functions. They decode the data coming 
from the remote host and translate them to 
a standard format to be used by the GUI. 
Tags used for various headings are 
translated into English; time and date 
stamps are put into a common format; and 
user prompts are eliminated. The data 
filters are built into the communications 
agents. The filters are maintained by the 
developers. 

Utilities and Bulletin Boards 

Everything that falls under the Bulletin 
Boards and Utilities main icons are tools 
that are freely distributed on the Internet. 
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They are all X applications that work on a 
variety of hardware platforms and 
operating systems and have been 
integrated into the NAM for ease of use 
for the NASA STI user community. The 
table below shows which utilities were 
available under these icons for the ALPHA 
prototype. 


Utility 

Actual Program 

iJsenet News 

nn news reader 

ARCHIL 

xarchie version TX 

Local Time 

xclock 

Weather Forecast 

xforecast 

Weather Maps 

tetchmaps and 
xloadimage 


manipulation, and the presentation of the 
application stayed essentially the same. 
Several of the changes were made as users 
were beta testing the system and citing 
problems to the developers. A list of the 
major changes from the alpha version to 
the beta version are noted below. 

GUI 

The beta version gained increased 
performance by keeping all data structures 
in memory. The alpha version used a 
number of temporary files to store data 
downloaded from remote databases. This 
change was a major efficiency and speed 
gain at the expense of larger memory 
requirements. 


Table 3. Alpha Version Utilities and 
Bulletin Boards 

Peer Locator 

This module consists of the following 
tools: 

• finger 

• NASA Phone Book 

• whois 

Query-by-form interfaces are provided to 
all of these tools as well as a pop-up email 
function. This allows a user to click on the 
email address of the person being searched 
for and immediately send mail without 
typing the address of the recipient. 

The UNIX finger and whois commands are 
available to dynamically query NASA and 
non-NASA machines. The NASA Phone 
Book provided in NAM is a static 
collection of digital telephone directories 
obtained from die NASA Centers during 
the beginning of the prototype. These data 
are stored in a local Ingres database 

n.C. BETA 
IMPLEMENTATION 

II.C.l. System Redesign 

The beta version of the software addressed 
many internal problems dealing with data 


In the alpha version the INGRES database 
calls were hard coded into the XI 1 GUI. 
This dependency was removed. A new 
network server process was created (called 
ingd). Now the GUI establishes a 
connection to the database server when 
queries are made via the Source Locator or 
NASA digital Phone Book. 

The GUI was split into two separate XI 1 
client programs. The xconnect program 
was responsible for establishing a 
connection to the NAM server (namd), 
controlling the query by forms screens, 
and for translating the query to be sent to 
the remote database. The xnam program 
was responsible for displaying the main 
icon box, providing job control for 
invoked processes, and invoking xconnect 
when connections to the formal data 
sources were required. The following 
major changes were also made: 

• Under the data sources icon, additional 
sources were made available. 
MEDLINE and Chemical Abstracts 
were made available through STN as 
requested by some of the beta testers. 

• STN was no longer searchable by 
journals. 

• The file D collection within NASA 
RECON was disabled due to the fact 
that there are limited access records 
there which could not be made 
available to the general public. 
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Native mode connections were added 
to support expert searchers who did not 
wish to be restrained by the forms 
interface. 

A number of the selection screens were 
simplified or removed. 

An optional status window was created 
to record billing costs for the various 
databases. 


teequest 

Description ■ 

help 

ketum list of va hcF 
commands 

dblist 

Return list of databases 

Subject list 

Return list of subjects 

locatedb ^’subject" 

Locate db based on 
subject 

locperson "first” 
"middle" "last" "code" 
"center 

Return phonebook data 


Table 4. Defined Set of Requests 


• The long citation display was 

formatted for easier reading by using 
bold facing and an easier to read 
format. 

Intelligent Source Locator 

The intelligent resource locator module 
provides information about the various 
remote sources and their coverage of 
subjects of interest to the users. It provides 
a mechanism to update a source’s 
relevance score for the chosen subject, 
based on the user’s disposition of search 
results from that source. The locator was 
changed to use a new program called ingd 
to query the Database of Databases which 
maintains the records of remote sources, 
their subject coverage, and relevance 
scores for each subject. 

Database Server 

In the alpha version the INGRES database 
calls were hard coded into the XI 1 GUI. 
This dependency was removed in the beta 
version. A new network server process 
was created (called ingd). Now the GUI 
establishes a connection to the database 
server when queries are made via the 
source locator or NASA digital 
Phonebook. 

The ingd is a concurrent server that 
accepts a set of well defined requests, 
queries the database server, and returns the 
results. See Table 4. 


Email 

Electronic mail is provided in two basic 
flavors. There are email interfaces such as 
Elm and ZMail provided to allow users to 
send, receive, filter, and file their 
electronic mail. There is also a custom 
"pop up" mail interface available in the 
Data Sources and Peer Locators. This 
facility is used to email search results to 
the user when searching the data sources. 
It’s also used in the Peer Locator when a 
search yields a email address. 

Utilities and Bulletin Boards 

A number of useful tools became available 
on the Internet and were incorporated 
under the Bulletin Board and Utilities 
icons. They included ARCHIE, mosaic 
and gopher. Weather maps and satellite 
images were also made available to 
demonstrate to users the capability to 
download graphics. 


Table 5 shows the publicly available 
programs incorporated into the Beta 
Prototype. 


Utility 

Actual Program 

Usenet News 

xm version 6. 1 7 

ARCHlii 

xarchie version 1 .3 

WAIS ” 

xwais from free W f AlS - 
0.1 

World Wide Web 

xmosaic version 1 . 1 

Gopher 

xgopher version 1.3 

Local 'time 

sunclock 

Weather forecast 

xforecast 

Weather Maps 

fetchmaps and 
xloadimage 


Table 5. Beta Version Utilities and 
Bulletin Boards 
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Peer Locator Tools 

Under the peer locator icon, the Knowbot 
and DNS queries were removed. The 
Knowbot program did not work properly, 
and the DNS query function was not 
useful or understandable by most users. 
The X.500 services were added because 
NASA, as an agency, had decided to 
support X.500 Directory Service Agents 
(DSA’s) at each of the NASA Centers to 
simplify electronic mail addressing. The 
Digital NASA phonebook that we had 
originally collected was allowed to 
stagnate since an up-to-date X.500 system 
seemed provide current data. 

II.C.2. Hardware/Software/Network 
Requirements 

For the prototype test, the NAM software 
was maintained on a single server with the 
IP address nova.sti.nasa.gov, in Arlington, 
Virginia; both the NAM client and the 
server ran on that machine. This processor 


is connected to the Internet via the NASA 
Science Internet (NSI). Users received an 
account on nova.sti.nasa.gov, connected 
via the Internet, and then executed the 
application; the display of each session 
was transmitted back to the user's local 
workstation and displayed using an X 
Window manager. Thus there were two 
basic requirements of beta testers: 1) their 
PCs, Macs, or UNIX workstations had to 
have TCP/IP connectivity to the Internet, 
and 2) they had to be able to display an X 
Window. See Figure 3. 

The first requirement, Internet 
connectivity, eliminated many of the 
NASA libraries from the beta test, since 
most did not have TCP/IP connectivity to 
the Internet. Other libraries were not 
allowed to participate because their local 
network administrators felt that X 
Window-based applications would cause 
too much network traffic on their local 
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area network. This was not true, but they 
could not be persuaded otherwise. 

The second requirement, X- Window 
capabilities, did not eliminate many NASA 
employees or on-site contractors; the 
majority of these beta testers already had 
the X Windows display capability. Where 
necessary, the NASA STI Program was 
able to supply limited numbers of users 
with the X server software needed for PCs 
and Macs, including eXodus, eXceed, or 
XVision for the PC, and MacX or eXodus 
for the Macintosh. For the UNIX 
workstations, no software was purchased, 
since X Windows capability is generally 
included with that class of workstation. If 
not supported by the vendor for a 
particular UNIX workstation, the entire 
XI 1 Release 5 is available at no cost on 
the Internet via anonymous ftp. 

II.C.3. Beta Test Participants 

The requirements analysis report 
recommended testing the prototype with a 
minimum of fifty users for a period of six 
months. After the initial demonstration of 
NAM at the STI Managers' Meeting in 
Houston in April 1992, we solicited 
participation from the NASA Center 
libraries. Our hope was that the libraries 
would both participate as users in the beta 
test and assist in assembling a good 
sample of end-users by displaying the 
system in an open area. However, network 
connectivity requirements eliminated most 
of the Center libraries that wanted to 
participate in the beta test. Only three beta 
testers came from the libraries or library 
referrals; the majority of the beta testers 
were people who saw NAM demonstrated 
by a colleague or at a trade show and 
wished to participate in testing. 

Participants for the beta test were limited 
to NASA employees and contractors who 
were U.S. citizens. 

As word of the prototype spread, the NAM 
team began receiving requests for beta test 
accounts. This resulted in gradual growth 
in the number of beta testers to a total of 
forty by the end of the test period, instead 
of a sample of fifty testers for the entire 


six-month period. A complete list of the 
participants and their organizations are 
listed in Appendix A. 

H.C.4. Schedule 


Date 

Phase 

Nov-91 

Technical Design 

Dec-91 

Start Development 

Apr-92 

Alpha Demo @ STI Conf. 

Jun-92 

Original Alpha Due Date 

Aug-92 

Disk Drives Delivered 

Dec-92 

Begin Beta Test With Six 
Users 

Jan-93 

Present NAM at AIAA 
Meeting 

Jan-93 

Add 14 Testers 

Feb-93 

Add 10 Testers 

Apr-93 

Add 1 Tester 

May-93 

Add 9 Testers, GCN Article 

Jun-93 

End Official Beta Test 

Jul-93 

Computerworld Article 

Jul-93 > 

Over 250 Inquiries 


Table 6. Project Schedule 

The requirements analysis report was 
delivered in March 1991. Market analysis 
began immediately to determine if there 
were suitable products available (from 
commercial or other sources) to meet the 
requirements. In July 1991, the 
development team was assembled and 
conceptual design began; in November 
1991, technical design started. 
Development of the software began in 
December of 1991, with a due date of June 
30, 1992 for demonstration of the alpha 
version. In February, 1991, the schedule 
was changed, to have a demonstration of 
the system at the April, 1992 STI 
Managers' Meeting. On April 28, a 
working version of the NAM was 
demonstrated to attendees at that meeting. 

During the summer of 1992, additional 
disk drives were procured to provide the 
additional space for user accounts; during 
this time, the alpha version was revised to 
include more tools and to make the 
software more robust. Also during this 
time, many vendors' versions of the X 
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server software for Macintosh and PC 
platforms were evaluated, and the 
packages to be supported were selected. 
Internal testing was performed by the 
development team and JTT users, and a 
user's manual was produced. 

The beta version of the software was 
completed in the fall of 1993, and beta 
testers were solicited in November 1993. 
The six-month testing period began 
December 1, 1992 and was completed 
May 31, 1993. Users were added 
gradually, since the majority of the users 
nominated themselves for the beta test 
after seeing the NAM on a colleague's 
desktop or at an exhibit. Thus, most users 
formally evaluated the NAM over a period 
shorter than six months. At the end of the 
beta test period, users were sent evaluation 
forms via electronic mail for response by 
the same mechanism. 

II.C.5. What Did We Provide? 

We provided users with an account on our 
Sun processor (nova.sti.nasa.gov). They 
executed the NAM GUI (both the NAM 
client and server) on nova, and displayed it 
to their local workstation over the Internet. 
We provided electronic mail and telephone 
support to users needing assistance with 
NAM operation. We also provided initial 
on-site support for users installing X 
server software on personal computers or 
Macintosh workstations. After a number of 
users had begun using the NAM with no 
training from the development team, we 
visited some user sites to offer them 
training, user manuals, and demonstrations 
to other potential users. We provided each 
user with a user manual if they wanted 
one. 


II.C.6. Statistics on Responses 

Users were electronically mailed a 
questionnaire about the prototype 
application. A copy of the questionnaire is 
in Appendix A. The answers to the 
questionnaire (with names omitted) are 
provided in Appendix B. 

User feedback was collected via electronic 
mail responses. Unfortunately, only a 
small number of the beta testers responded 
to the questionnaire. The collected 
responses were tallied and analyzed. 

As illustrated in Figure 4, the most widely 
used portion of NAM was the Data 
Sources icon. The graph shows statistics 
based on actual number of transactions 
performed during the official beta test 
period. Bulletin Boards, which were 
actually the Internet tools, and others, 
which were the weather maps, were the 
next most popular items. 



Figure 4. NAM Use by Icon 
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CHAPTER THREE - 
Lessons Learned 

HI.A. DEVELOPERS' 

FINDINGS 

III.A.1. Findings During Development 
and Testing 

Local Availability of NAM GUI 

Developers found the biggest problem to 
be the slowness of the interface when the 
application was run remotely (as was 
done in the beta test). The problem was 
that we were running an X application 
over a wide area network (WAN), which 
caused the throughput to be very slow. If 
the X application approach is to be 
successful, local concentrations of X- 
based NAM users should be served by a 
local machine capable of running the 
NAM GUI to attempt to maintain the 
high-bandwidth requirement between the 
X application and the X display on a 
local area network (LAN) . This would 
require that at least one machine be 
located at each site that would be 
capable of running the NAM GUI for 
people who can not run the GUI on their 
desktop machine (i.e., PCs and 
Macintosh computers). Users with UNIX- 
based machines with XI 1R5 and Motif 
installed would be best served by 
installing the application on their own 
workstations. 

Native Clients are Needed for Each 
Supported Platform 

The deployment of the prototype to the 
different NASA centers pointed out the 
difficulty in getting an X-Window 
system running reliably in many 
different hardware environments. The 
support of IBM-PCs and clones was 
especially difficult due to the many 
differences in hardware/software 
configurations encountered in the beta 
test community. 


X.500 More Useful Than Electronic 
Phonebook 

The developers stopped updating the 
electronic phonebook because it required 
them to continually obtain electronic 
versions of the phonebook from each 
center. Each centers' data was in a 
different format, which made this 
difficult. Using each centers' X.500 
online directory for the phonebook 
information proved to be more useful, 
since NASA has made a commitment to 
keep information in these directories 
current. It was found, however, that 
people didn't select X.500 under peer 
locators because they didn't know what it 
did; instead they chose the NASA 
Phonebook option. The X.500 option 
should have been renamed to reflect its 
function. 

Limited Internet Connectivity to 
Libraries 

Before the beta test phase began, it was 
assumed that each NASA library would 
have a running version of the NAM 
located in an open area of the library. It 
was soon learned, however, that most of 
the libraries did not have access to the 
Internet from local machines. Some 
libraries did have access, but their LAN 
administrators did not want X 
applications running locally because 
they thought they would cause networks 
bottlenecks. This lack of connection with 
libraries placed limits on the Beta Test. 

Lack of Adequate Platforms 
Eliminated Some Testers 

Many people expressed great interest in 
becoming beta testers, but could not due 
so because their workstations did not 
meet the minimum system requirements. 
The X Server software required 
Microsoft Windows on DOS machines, 
with at least 8 MB of memory and a 
VGA monitor. Many systems, especially 
in the libraries, did not meet these 
requirements. Macintosh platforms with 
small monitors and low memory were 
also eliminated. 
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PC Xserver Software Selection 
Cumbersome 

A study was done of existing Xserver 
software to determine the one which was 
best suited to run the NAM application. 
The testing and selection of this software 
took longer than planned, and the selected 
packages still had occasional bugs. 

Dial-in connection to the NAM was 
supported for demonstrations and exhibits. 
XRemote performed better than the other 
serial protocols, PPP and SLIP, for dial-in 
connections to the NAM, using a 9600 
baud modem. XRemote is a proprietary 
communications protocol developed by 
NCD. It falls under a technology category 
referred to as Low-Bandwidth X (LBX). A 
standard for LBX is expected in XI 1/R6, 
to be released in early 1994. 

Users Like the Expand Feature 

The expand feature allowed users to search 
for an author or title, and choose from a 
list of terms that were close to the one 
searched. Users liked this feature because 
they did not have to know exactly how to 
spell an author's name or how it was 
entered into the database. 

III.A.2. Findings From Log Files and 
Monitoring 

Intermediate Form Used Most 

Results showed that the Intermediate 
query form, which allowed users to query 
on words or phrases found in the abstracts 
of documents, was used more than the 
novice or expert. The most common type 
of query was based on Author name, 
followed by Subject/Keyword queries. The 
Intermediate form supported both these 
query types. 

Electronic Phonebooks Popular 

Electronic phonebooks were widely used. 
This capability will be enhanced as more 
corporate and national electronic phone 
books and directories become available. 
The directories need not be global to be 
useful. Often the organizational level 
directories were used. 


III.B. USERS’ FINDINGS 
Testers Loved It! 

The most common comment was "This is 
great!” The testers were very happy to 
have access to NAM, and many have 
incorporated it’s use into their everyday 
work. That's not to say that there is no 
room for improvement. During the process 
of beta testing, users responded with 
comments and recommendations for the 
modification of the functional 
requirements for NAM. 

Slow Response Time 

The most often heard comment from users 
was that the NAM application was too 
slow. The NAM GUI used by the beta 
testers ran from a machine in Crystal City, 
Virginia. The GUI was then displayed on 
the user's workstation over the Internet. 
This meant that every keystroke and every 
click of the mouse button had to go over 
the Internet and back for the user to see 
anything happen. As a result, the 
application was slow. 

Type of Training Desired 

Generally, the testers felt personal training 
from a knowledgeable user, plus a 
combination of online instruction (tutorials 
and more extensive help screens) was the 
best training environment. They felt the 
help screens in the beta test version were 
not very helpful. 

More Sources of Information Needed 

Most of the users found the NAM 
interface so useful that they wanted to add 
more data types and sources of 
information to those currently available. 

On average, each user had one or two 
additions to the information sources 
provided through the prototype. Types of 
information requested were as follows: 

• Full text 

• All NASA papers and technical reports 

• Product reviews and descriptions 

• Science Citation Index 

• Readers’ Guide to Periodicals 

• Standard reference works 

• NASA program descriptions 

• NEXUS, LEXIS, DIALOG 
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• GeoRef 

• Non-textual databases 

• NASA budget information 

• Physical properties tables; flow 
properties 

• Database of people and their expertise 

• NASA satellite data (EOSDIS, 
NSSDC) 

• NASA software available for reuse 

• COSMIC catalogue 

• Educational software 

• Images 

• Planetary and lunary images available 
from JPL 

• Publicity images available from Public 
Affairs offices 

• Property database (flow database) 

• Numerical databases 

• Citations index 

• Commercial information (Thomas’ 
Register) 

• NASA Thesaurus 

• DIALOG 

• CIA word FACT Book 

• Softlib 

Single Query Against Multiple Sources 

Users would like an option to have the 
system determine appropriate remote 
host(s) for a topic, and have the system 
execute the query against the appropriate 
source(s). Users should have control of the 
querying process in all phases (for 
example, to edit the list of remote sources 
chosen for execution, or not; to view 
intermediate results, or not, etc.) 

Selective Dissemination of Information 
Some users would like the option of 
creating a standing topic of interest to be 
executed automatically or at the user’s 
request (also known as selective 
dissemination of information). 

Usenet News Filter 

Some users thought it would be useful to 
be able to query Usenet News categories 
for specific information so they would not 
have to search through many messages to 
find something of interest. 


Full Text Retrieval 

Once abstracts are retrieved users would 
like to access full text documents. This has 
been a requirement mentioned by a 
majority of the users and should be given 
high consideration. 

Search and Retrieval Techniques 

Users want to expand their search and 
retrieval techniques to include tools other 
than Boolean logic, such as relevance 
feedback, natural language queries, and 
spatial, range, and proximity searching. 

User Customization 

Users want the ability to customize the 
query screen to suit their individual search 
needs. 

Local Printing Requested 

Once information is retrieved, users need 
the option to print the results locally at 
their site. Currently the system directs 
output to a printer attached to the NAM 
server in Crystal City. 

Action Items Needed for Short Citations 

Options currently available for long 
citations, such as print, save, and FAX, are 
needed on the short citations screen as 
well. Many users know a document is 
needed simply by looking at the title and 
do not want to view the long abstract 
before acting on it. 

Perform Actions on Multiple 
Documents 

Users would like to be able to act on more 
than one document at a time. For instance, 
if they found 50 documents through a 
search in their area, they would like to be 
able to mail them all to themselves or 
choose more than one at a time. 

Post Processing Tools 

Users requested that post processing tools 
be available to allow specific 
transformations to be performed on data 
obtained from searches. An example given 
is a duplicate elimination process that 
would delete multiple instances of the 
same data found in multiple sources. 
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Data Visualization 

Many sites store data that is non-textual in 
format. The ability to have various file 
formats, such as postscript files or 
numerical data, translated automatically 
into a readable image is desired by users. 

Language Translation 

Users need to translate foreign language 
files as they are transported as well as the 
terms on which they are searched. 

Graphicsl User Interface (GUI) to 
Databases Easy to Use 
The GUI concept was applied to 
bibliographic database queries by a form 
on which users filled in blanks 
corresponding to attributes of the remote 
database. The forms were the same 
regardless of the remote database. Users 
had no difficulty using the forms for single 
queries and found them to be much easier 
than learning the query language native to 
the database being searched. Professional 
searchers felt that the forms could be made 
more effective by the addition of tools to 
use the remote source’s Thesaurus and 
Frequency functions when available. 

Minimum Training Required 
The NAM Prototype has been used 
successfully by NASA engineers with no 
prior training other than a demonstration 
lasting less than one-half hour. The unique 
combination of tools to access internal and 
external information, formal and informal 
sources, peer location and Internet utilities 
is applicable in various user environments. 
Users liked the fact that they did not need 
a lot of training to use the NAM. 

Electronic Phonebooks Popular 

Users liked the digital phonebooks to find 
information about their peers and found 
them very useful. They especially found 
the email addresses helpful. 

Desktop Access to Infromation Saves 
Staff Time 

Users were asked to estimate the time 
and/or money they would save per year if 
they had the NAM available to them from 
their desktop. Individual estimates of 
savings ranged from a low of at least one 


week per year to several weeks per year, 
and a high of $20,000 per year. 

Uses of Desktop Information Access 

Users found that they used NAM mostly to 
stay current in their field or prepare a 
presentation or paper. The next most 
important use was to find an expert for 
collaboration or to help solve a problem. 
After that the most popular use was to 
prepare/refine a project proposal. Others 
used the NAM to train library patrons or to 
find references via author search. 

Predicted Use of NAM 

Users were asked to predict the frequency 
with which they would use the various 
facilities provided by the prototype. Users 
predicted that they would use all facilities, 
with a frequency of use for different 
facilities ranging from once per month to 
several times per day. 

Users predict that they would use mail and 
bulletin boards most frequently, followed 
by access to data sources (in order of 
frequency: ARIN, and Inspec) followed by 
utilities and peer locators. 

IILC. PUBLIC DEMONSTRATIONS 
AND TRADE PRESS REACTIONS 

In January, 1993, the STI Program exhibit 
staff began to demonstrate the NASA 
Access Mechanism at various trade shows, 
exhibits, and conferences throughout the 
United States. Public reactions to the 
NAM varied with the particular exhibit 
attendees. 

Audiences consisting mostly of 
researchers and NASA employees or 
contractors were very interested in the 
Data Sources portion of NAM. They were 
thrilled to find that someone was trying to 
make commonly used databases such as 
STN and RECON user friendly. Most 
audiences said they currently went to their 
site library to have searches done for them, 
and they disliked having to physically go 
there and then wait for the search being 
performed. Many people did not know 
what RECON was; they simply knew that 
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their librarian found information from 
some database inside NASA. After a short 
demonstration of the NAM they were very 
impressed with the simplicity, and the next 
question was always, "How can I get it?" 
or "When will this be available to the 
public?" 

Exhibits that were tailored towards new 
technology brought different responses 
from attendees. These audiences were 
more interested in the Internet tools than 
the database search mechanisms. They 
were excited to see that they could have 
tools such as WAIS, Gopher, Usenet and 
World Wide Web available to them 
through one single application. They also 
wanted to know how they could get NAM 
put on their desktop workstation. 

Although there was a great deal of interest 
from conference attendees in becoming 
beta testers for NAM, many of them did 
not qualify. Some conferences had many 
attendees from commercial firms to which 
we could not supply the software. Many of 
the people did not have Internet access at 
their desktop, so they would not be able to 
use NAM. Others became uninterested 
when they found out they needed to 
purchase the Xserver software to use 
NAM on a PC or Macintosh. Generally 
comments were positive from all groups, 
and they wanted to know when the 
software would be publicly available. 

As more people learned about the NAM, 
interest continued to grow. On May 24, 
1993 Government Computer News 
published an article titled, "NASA's 
Homegrown GUI Scores Big With Beta 
Testers." (see appendix). This article 
focused primarily on the background of 


the NAM project, the systems on which it 
runs, and the data source portion of the 
software. It mentioned the other functions 
of NAM but did not go into great detail 
about them. This article generated interest, 
but did not give a point of contact to the 
readers. Some people still managed to 
track down the STI program by asking 
NASA employees how to contact the 
programmers listed in the article. 

On July 5, 1993 Computerworld published 
an article titled, "NASA’s GUI Makes the 
Internet User Friendly." (see 
appendix).This article focused on the 
modularity of the NAM software and 
graphical user interface to the Internet. 

The article also informed readers that they 
could learn more about NAM by sending 
email to nam@sti.nasa.gov, which 
forwarded the messages to all members of 
the NAM team. This article generated 
interest from over 250 readers who wanted 
to know when NAM would be available to 
the public and how they could learn more 
about it. Those interested received 
instructions on how to download a 
technical NAM paper using FTP or a 
gopher client. More people are getting 
connectivity, but need help navigating 
their way to useful information. Many 
thought that having several tools available 
through one piece of software was an 
excellent idea and they wanted to try it 
themselves. The NAM team was very 
surprised to learn that most of the interest 
in the NAM software was based on the 
tools, not the database search utilities as 
planned. Tools such as WAIS, gopher, and 
WWW are publicly available to everyone, 
but many people do not know how to 
obtain them and make them run. 
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CHAPTER FOUR ■ 
Options 

IY.A. CREATE NAM-Lite 

The existing NAM application could be 
modified so the NAM GUI could be 
distributed to users. The server portions of 
NAM can still be run in a more controlled 
environment. It is recommended that the 
following changes be made to the current 
NAM system to create NAM-Lite: 

• User authentication 

• Limit to RECON, STN and DIALOG 
connectivity 

• Only intermediate and native screens 

• Basic peer locator tools provided 

• Top level icons modified 

• Group/Set operations 

• Screens for new account information 

• Automatic link to thesaurus 

• Source locator redone 

• Added Peer Locator tools 

The NAM-Lite program should still 
contain the functionality of RECON and 
STN. Adding DIALOG as a database 
source would fill the majority of user 
requests for external sources. User 
authentication will need to be built into the 
system to allow a user to maintain and 
modify his/her own passwords and userid 
information. The user will have the option 
of using STN, DIALOG and RECON, as 
with the current system, but if they do not 
have an existing account they will be 
presented with an informative page on 
how to get accounts either online or by 
contacting the respective agency. Once an 
account has been established, the user will 
be transparently connected to the remote 
system as with the current version of 
NAM. 

NAM-Lite should only limit the search 
form to the intermediate and native 
screens. The novice screen is unnecessary 
because the intermediate screen allows for 
more complex searches by the experienced 
user but does not make a simple search 


strategy any more complicated to the 
novice user. The native mode will be 
available for those expert users of 
RECON, STN, or DIALOG. The expert 
screen will be dropped because it is 
somewhat limiting for true expert users 
who want to search using the native 
system query language. 

Basic peer locator tools will still be 
available with NAM-Lite. The digital 
Phonebooks will be dropped because they 
are too difficult to keep current. The X.500 
service will be available and possibly 
renamed digital phonebook. Other basic 
services such as finger, netlib, and whois 
will remain the same. Adding a new 
service class such as NetFind would 
greatly enhance the user's capabilities to 
locate individuals. 

The top level icons will be modified with a 
whole new look to differentiate them from 
the current version of NAM. There will 
only be three main buttons, which will be 
Data Sources, Peer Locator, and Tools. 

The tools button will be a user-defined 
button with which users can link local 
applications, such as email, WWW, WAIS 
and gopher. 

NAM-Lite should include the capability to 
perform group operations. Users will be 
able to select all or multiple sets of data 
and perform group operations on them 
such as printing, faxing, or mailing. 

An automatic link to the thesaurus will be 
implemented in NAM-Lite. Users will be 
able to search on terms, but if they are 
unclear about a term they can 
automatically bring up a thesaurus to assist 
them. 

The source locator needs to be updated to 
connect to accessible file collections and 
reflect access to collections by user id. 
Users would be able to connect to 
classified information if their user id was 
of a certain class. 

Once NAM-Lite is created it can be 
distributed to the NASA community. 
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NAM-Lite would replace the current 
version of the NAM that is being run 
remotely by users; it would be run locally 
to obtain maximum speed, which has been 
a large problem. 

The same NAM-Lite described above 
could be made available to the public. The 
user authentication process, which gives 
instructions on how to obtain an account, 
may spark interest for potential users at 
universities and research institutions to 
obtain RECON accounts. 

The GUI should be ported to other UNIX 
variants such as IRIX, HP-UX, and AIX. 
This would allow for a larger community 
of potential users to take advantage of the 
NAM-Lite. 

IV.B. USE WORLD WIDE WEB 
FORMS 

Implement the functions of the formal data 
sources access using the forms 
functionality of Mosaic/WWW. This will 
allow us to leverage from the work done at 
the National Center for Supercomputing 
Applications (NCSA) on Mosaic. This 
approach also allows the limited support 
capabilities of the STI Program to 
concentrate on the service aspects of the 
NAM rather than concentrating on the 
development of native clients. Currently, 
NCSA provides native clients for UNIX 
(XI 1/OSF Motif), MS-Windows, and 
MacOS platforms. 

IV.C. CREAT NATIVE CLIENTS 
WITH SMALL REWRITE 

Native clients could be written for PC 
(DOS and Windows) and Macintosh 
platforms that would provide the same 
functionality as the current NAM system. 
The European Space Agency (ESA) has 
developed a MS-Windows based product 
called BRAQUE (BRowse And QUEry). 
This system allows PC users connected to 
either a TCP/IP Internet or via an 
asynchronous modem to connect to ESA’s 
QUEST system and perform searches 
using a GUI query-by-forms capabilities. 


Since the QUEST system takes as its 
origins the same software that RECON 
uses, it is anticipated that modification of 
the source code of BRAQUE to work with 
RECON would not be too extensive. This 
would give the STI Program a quick and 
inexpensive PC platform native client. The 
ESA folks have stated that they would be 
willing to give the STI program a copy of 
the source code for this purpose. 


IV.D. CREATE FRONT END FOR 
INTERNET TOOLS 

The icon of the NAM called Bulletin 
Boards provided the user with a front end 
to public domain software such as WWW, 
Archie, gopher, and WAIS. These 
applications proved to be a very popular 
portion of NAM and could be isolated into 
a separate GUI providing easy access to 
commonly used Internet tools. 


The entire design of the NASA Access 
Mechanism needs to be reconsidered, 
redesigned, and reimplemented. A new 
design specification should be written to 
alleviate problems with the current system 
and to take advantage of new technology. 
An Object Oriented Design (OOD) should 
be used. A GUI that may be easily tailored 
to individuals or small groups needs 
should be provided. The GUI should be 
implemented natively under UNIX/X, 
MacOS, and Microsoft Windows. New 
tools and services need to be provided to 
help users locate and access the data 
sources they need. 

TV. F. THROWAWAY NAM 

The first option is to remove all access to 
the current system. What has been learned 
from the prototype can be incorporated 
into the NASA STI Program’s RECON 
Replacement system. This is not a viable 
option unless the RECON Replacement is 
implemented in a timely fashion. 
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IV.G. OTHER CONSIDERATIONS 

Issues of distribution, support, and access 
rights need to be considered. Any user 
community to whom we provide access to 
a potential new version of NAM needs to 
be made aware of data access restrictions. 
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CHAPTER FIVE - 
Recommendations 

V.A. SHORT TERM 

Both the NAM-Lite version and a 
WWW/Mosaic Forms version of NAM 
GUI should be developed and made 
available to the NASA user community as 
soon as possible. These recommendations 
suggest interim measures designed to 
serve our user community until the formal 
RECON replacement is made available. 

The NAM-Lite implementation would be 
made available in both source and binary 
forms to allow maximum outside exposure 
and encourage outside enhancements. The 
use of either COSMIC and/or anonymous 
FTP as distribution medium sites is 
strongly encouraged. 

The WWW/Mosaic Forms version, on the 
other hand, does not require a distribution 
medium, as the form would simply be 
made available on the STI’s WWW server. 
This would be a HTML document that 
would be interpreted by WWW clients 
such as Mosaic. 

Operational support of the NAM-Lite 
version should be provided by the 
Information Services Section of the STI 
Program. Maintenance of the code should 
be limited to bug fixes and minor 
enhancements only. 

Versions of NAM-Lite must be ported to 
other common platforms (UNIX, PCs and 
Mac's). 

V.B. LONG TERM 

Native clients for MS-Windows, 

MacOS, and XI 1 

The possibility of modifying the 
ESA/BRAQUE software to work for MS- 
Windows platform should be researched. 
Native clients for Macintoshes also need to 
be developed. The parts of the current 
client that are unique should remain 


consistent from client to client. For other 
applications that we have integrated like 
gopher, WAIS, email, etc. we should use 
the best native client that is available in the 
public domain. 

V.C. MANAGEMENT 
RECOMMENDATIONS 

It is recommended that the current NAM 
prototype system be modified in a timely 
manner so that it can become available to 
the NASA user community as quickly as 
possible. Functions that are out of date or 
not used will be removed from the system, 
and remaining functions will be updated as 
described in the previous section. This 
new version of the product will be known 
as NAM-Lite. Once the product is ready 
for distribution, the team should do 
whatever is needed to get the libraries to 
use the system. The NAM-Lite system 
should act as an interim system until the 
RECON Replacement system is in place. 
Once the RECON Replacement system is 
in place, the Program will need to evaluate 
the need for keeping NAM-Lite 
operational. 

Once an operational system is in place, 
support of the NAM product should be 
transferred to the Information Services 
Section of the STI Program. Training will 
be supplied for the Help Desk staff at 
CASI so they can handle the questions 
they receive on a daily basis. 

Functions that provide users with an 
interface to the Internet utilities should be 
isolated and distributed as a separate 
system via COSMIC. 

It is also recommended that the NASA STI 
Program’s Engineering Review Board 
discuss the role NASA wants to play in 
providing a system like NAM to the user 
community. Does the Program want to 
support the system forever or distribute the 
software and let the Centers and Program 
Offices do as they want? This is a strategy 
question which will need more discussion. 
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GLOSSARY 

agent . . 

In the client-server model, the part of 
the system that performs information 
preparation and exchange on behalf of 
a client or server application. 

American Standard Code for 

Information Interchange (ASCII) 

A standard character-to-number 
encoding widely used in the computer 
industry. 

anonymous FTP 

Anonymous FTP allows a user to 
retrieve documents, files, programs, 
and other archived data from anywhere 
in the Internet without having to 
establish a userid and password. By 
using the special userid of 
"anonymous" the network user will 
bypass local security checks and will 
have access to publicly accessible files 
on the remote system. 

AppleTalk 

Apple Computer's suite of protocols 
that enables the hardware and software 
on an AppleTalk network to interact 
and to route data. 

application 

A program that performs a function 
directly for a user. FTP, mail, and 
Telnet clients are examples of network 
applications. 

application layer 

The top layer of the network protocol 
stack. The application layer is 
concerned with the semantics of work 
(e.g., formatting electronic mail 
messages). How to represent that data 
and how to reach the foreign node are 
issues for lower layers of the network. 

Application Program Interface (API) 

A set of calling conventions which 
define how a service is invoked 
through a software package. 


archie 

A system to automatically gather, 
index, and serve information on the 
Internet. The initial implementation of 
archie provided an indexed directory 
of filenames from all anonymous FTP 
archives on the Internet. Later versions 
provide other collections of 
information. 

archive site 

A machine that provides access to a 
collection of files across the Internet. 
An "anonymous FTP archive site," for 
example, provides access to this 
material via the FTP protocol. 

authentication 

The verification of the identity of a 
person or process. 

backbone 

The top level in a hierarchical network. 
Stub and transit networks that connect 
to the same backbone are guaranteed to 
be interconnected. 

bandwidth 

Technically, the difference, in Hertz 
(Hz), between the highest and lowest 
frequencies of a transmission channel. 
However, as typically used, bandwidth 
is the amount of data that can be sent 
through a given communications 
circuit. 

Berkeley Software Distribution (BSD) 
Implementation of the UNIX operating 
system and its utilities developed and 
distributed by the University of 
California at Berkeley. "BSD" is 
usually preceded by die version 
number of the distribution, e.g., "4.3 
BSD" is version 4.3 of the Berkeley 
UNIX distribution. Many Internet hosts 
run BSD software, and it is the 
ancestor of many commercial UNIX 
implementations. 

Bulletin Board System (BBS) 

A computer, and associated software, 
which typically provides electronic 
messaging services, archives of files, 
and any other services or activities of 
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interest to the bulletin board system's 
operator. Although BBSs have 
traditionally been the domain of 
hobbyists, an increasing number of 
BBSs are connected directly to the 
Internet, and many BBS's are currently 
operated by government, educational, 
and research institutions. 

client 

A computer system or process that 
requests a service of another computer 
system or process. A workstation 
requesting the contents of a file from a 
file server is a client of the file server. 

client-server model 

A common way to describe the 
paradigm of many network protocols. 
Examples include the name- 
server/name-resolver relationship in 
DNS and the file-server/file-client 
relationship in NFS. 

connection-oriented 

The data communication method in 
which communication proceeds 
through three well-defined phases: 
connection establishment, data 
transfer, and connection release. TCP 
is a connection-oriented protocol. 

connectionless 

The data communication method in 
which communication occurs between 
hosts with no previous setup. Packets 
between two hosts may take different 
routes, as each is independent of the 
other. UDP is a connectionless 
protocol. 

datagram 

A self-contained, independent entity of 
data carrying sufficient information to 
be routed from the source to the 
destination computer without reliance 
on earlier exchanges between this 
source and destination computer and 
the transporting network. 

DECNET 

A proprietary network communication 
protocol by Digital Equipment 


Corporation which is widely is use 
today 

Defense Advanced Research Projects 
Agency (DARPA) 

An agency of the U.S. Department of 
Defense responsible for the 
development of new technology for 
use by the military. DARPA (formerly 
known as ARP A) was responsible for 
funding much of the development of 
the Internet we know today, including 
the Berkeley version of UNIX and 
TCP/IP. 

Defense Data Network (DDN) 

A global communications network 
serving the U.S. Department of 
Defense composed of MILNET, other 
portions of the Internet, and classified 
networks that are not part of the 
Internet. The DDN is used to connect 
military installations and is managed 
by the Defense Information Systems 
Agency. 

Defense Data Network Information 
Center (DDN NIC) Often called "The 
NIC,” the DDN NIC’s primary 
responsibility is the assignment of 
Internet network addresses and 
Autonomous System numbers, the 
administration of the root domain, and 
providing information and support 
services to the DDN. It is also a 
primary repository for RFCs. 

dialup 

A temporary, as opposed to dedicated, 
connection between machines 
established over a standard phone line. 

Directory Access Protocol 
X.500 protocol used for 
communication between a Directory 
User Agent and a Directory System 
Agent. 

Directory System Agent (DSA) 

The software that provides the X.500 
Directory Service for a portion of the 
directory information base. Generally, 
each DSA is responsible for the 
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directory information for a single 
organization or organizational unit. 

Directory User Agent (DUA) 

The software that accesses the X.500 
Directory Service on behalf of the 
directory user. The directory user may 
be a person or another software 
element. 

Distributed Computing Environment 
(DCE) 

An architecture of standard 
programming interfaces, conventions, 
and server functionality (e.g., naming, 
distributed file system, remote 
procedure call) for distributing 
applications transparently across 
networks of heterogeneous computers. 
Promoted and controlled by the Open 
Software Foundation (OSF), a 
consortium led by Digital, IBM, and 
Hewlett Packard. 

distributed database 

A collection of several different data 
repositories that looks like a single 
database to the user. A prime example 
in the Internet is the Domain Name 
System. 

Domain Name System (DNS) 

The DNS is a general purpose 
distributed, replicated, data query 
service. The principal use is the lookup 
of host IP addresses based on host 
names. The style of host names now 
used in the Internet is called "domain 
name," because they are the style of 
names used to look up anything in the 
DNS. Some important domains are 
.COM (commercial), .EDU 
(educational), .NET (network 
operations), .GOV (U.S. government), 
and .MIL (U.S. military). Most 
countries also have a domain. For 
example, .US (United States), .UK 
(United Kingdom), .AU (Australia). 

Electronic Mail (Email) 

A system whereby a computer user can 
exchange messages with other 
computer users (or groups of users) via 
a communications network. Electronic 


mail is one of the most popular uses of 
the Internet. 

email address 

The domain-based or UUCP address 
that is used to send electronic mail to a 
specified destination. 

Ethernet 

A 10-Mb/s standard for LANs, initially 
developed by Xerox and later refined 
by Digital, Intel and Xerox (DIX). All 
hosts are connected to a coaxial cable 
where they contend for network access 
using a Carrier Sense Multiple Access 
with Collision Detection (CSMA/CD) 
paradigm. 

Federal Information Exchange (FIX) 

One of the connection points between 
the American governmental internets 
and the Internet. 

Fiber Distributed Data Interface (FDDI) 

A high-speed (lOOMb/s) LAN 
standard. The underlying medium is 
fiber optics, and the topology is a dual - 
attached, counter-rotating token ring. 

file transfer 

The copying of a file from one 
computer to another over a computer 
network. 

File Transfer Protocol (FTP) 

A protocol that allows a user on one 
host to access and transfer files to and 
from, another host over a network. 
Also, FTP is usually the name of the 
program the user invokes to execute 
the protocol. It is defined in STD 9, 
RFC 959. 

finger 

A program that displays information 
about a particular user, or all users, 
logged on the local system or on a 
remote system. It typically shows full 
name, last login time, idle time, 
terminal line, and terminal location 
(where applicable). It may also display 
plan and project files left by the user. 
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gateway 

The term "router" is now used in place 
of the original definition of "gateway". 
Currently, a gateway is a 
communications device/program that 
passes data between networks having 
similar functions but dissimilar 
implementations. This should not be 
confused with a protocol converter. By 
this definition, a router is a layer 3 
(network layer) gateway, and a mail 
gateway is a layer 7 (application layer) 
gateway. 

gopher 

A distributed information service that 
makes available hierarchical 
collections of information across the 
Internet. Gopher uses a simple protocol 
that allows a single Gopher client to 
access information from any accessible 
Gopher server, providing the user with 
a single "Gopher space" of 
information. Public domain versions of 
the client and server are available. 

Government OSI Profile (GOSIP) 

A subset of OSI standards specific to 
U.S. Government procurements, 
designed to maximize interoperability 
in areas where plain OSI standards are 
ambiguous or allow excessive options. 

host 

A computer that allows users to 
communicate with other host 
computers on a network. Individual 
users communicate by using 
application programs, such as 
electronic mail, Telnet, and FTP. 

hostname 

The name given to a machine. 

Interagency Interim National Research 
and Education Network (IINREN) 

An evolving operating network 
system. Near term (1992-1996) 
research and development activities 
will provide for the smooth evolution 
of this networking infrastructure into 
the future gigabit NREN. 


International Organization for 
Standardization (ISO) 

A voluntary, non-treaty organization 
founded in 1946 that is responsible for 
creating international standards in 
many areas, including computers and 
communications. Its members are the 
national standards organizations of the 
89 member countries, including ANSI 
for the U.S. 

internet 

While an internet is a network, the 
term "internet" is usually used to refer 
to a collection of networks 
interconnected with routers. 

Internet 

(Note the capital "I.") The Internet is 
the largest internet in the world. It a 
three-level hierarchy composed of 
backbone networks (e.g., NSFNET, 
MELNET), mid-level networks, and 
stub networks. The Internet is a 
multiprotocol internet. 

internet address 

A IP address that uniquely identifies a 
node on an internet. An Internet 
address (capital "I") uniquely identifies 
a node on the Internet. 

Internet Protocol (IP) 

The Internet Protocol, defined in STD 
5, RFC 791, is the network layer for 
the TCP/IP Protocol Suite. It is a 
connectionless, best-effort packet 
switching protocol. 

Internetwork Packet exchange (IPX) 

Novell's protocol used by Netware. A 
router with IPX routing can 
interconnect LANs so that Novell 
Netware clients and servers can 
communicate. 

interoperability 

The ability of software and hardware 
on multiple machines from multiple 
vendors to communicate meaningfully. 

Kermit 

A popular file transfer protocol 
developed by Columbia University. 
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Because Kermit runs in most operating 
environments, it provides an easy 
method of file transfer. Kermit is NOT 
the same as FTP. 

knowbot 

An experimental directory service. 

layer 

Communication networks for 
computers may be organized as a set of 
more or less independent protocols, 
each in a different layer (also called 
level). The lowest layer governs direct 
host-to-host communication between 
the hardware at different hosts; the 
highest consists of user applications. 
Each layer builds on the layer beneath 
it. For each layer, programs at different 
hosts use protocols appropriate to the 
layer to communicate with each other. 
TCP/IP has five layers of protocols; 
OSI has seven. The advantages of 
different layers of protocols is that the 
methods of passing information from 
one layer to another are specified 
clearly as part of the protocol suite, 
and changes within a protocol layer are 
prevented from affecting the other 
layers. This greatly simplifies the task 
of designing and maintaining 
communication programs. 

listserv 

An automated mailing list distribution 
system originally designed for the 
Bitnet/EARN network. See also Bitnet, 
European Academic Research 
Network, mailing list. 

Local Area Network (LAN) 

A data network intended to serve an 
area of only a few square kilometers or 
less. Because the network is known to 
cover only a small area, optimizations 
can be made in the network signal 
protocols that permit data rates up to 
lOOMb/s. See also Ethernet, Fiber 
Distributed Data Interface, Wide Area 
Network. 

mail server 

A software program that distributes 
files or information in response to 


requests sent via email. Internet 
examples include Almanac and netlib. 
Mail servers have also been used in 
Bitnet to provide FTP-like services. 

See also Electronic Mail, File Transfer 
Protocol. 

Multipurpose Internet Mail Extensions 

(MIME) 

An extension to Internet email that 
provides the ability to transfer non- 
textual data, such as graphics, audio 
and fax. It is defined in RFC 1341. 

National Institute of Standards and 

Technology (NIST) 

United States governmental body that 
provides assistance in developing 
standards. Formerly the National 
Bureau of Standards. 

National Research and Education 

Network (NREN) 

The NREN is the realization of an 
interconnected gigabit computer 
network devoted to High Performance 
Computing and Communications. 

National Science Foundation (NSF) 

A U.S. government agency whose 
purpose is to promote the advancement 
of science. NSF funds science 
researchers, scientific projects, and 
infrastructure to improve the quality of 
scientific research. The NSFNET, 
funded by NSF, is an essential part of 
academic and research 
communications. It is a high speed 
"network of networks" that is 
hierarchical in nature. At the highest 
level, it is a backbone network 
currently comprising 16 nodes 
connected to a 45Mb/s facility that 
spans the continental United States. 
Attached to that are mid-level 
networks and attached to the mid- 
levels are campus and local networks. 
NSFNET also has connections out of 
the U.S. to Canada, Mexico, Europe, 
and the Pacific Rim. The NSFNET is 
part of the Internet. 
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network 

A computer network is a data 
communications system that 
interconnects computer systems at 
various different sites. A network may 
be composed of any combination of 
LANs or WANs. 

network address 

The network portion of an IP address. 
For a class A network, the network 
address is the first byte of the IP 
address. For a class B network, the 
network address is the first two bytes 
of the IP address. For a class C 
network, the network address is the 
first three bytes of the IP address. In 
each case, the remainder is the host 
address. In the Internet, assigned 
network addresses are globally unique. 
See also : Internet. 

Network File System (NFS) 

A protocol developed by Sun 
Microsystems and defined in RFC 
1094 that allows a computer system to 
access files over a network as if they 
were on its local disks. This protocol 
has been incorporated in products by 
more than two hundred companies, and 
is now a de facto Internet standard. 

Network Information Center (NIC) 

A NIC provides information, 
assistance, and services to network 
users. 

Network Information Services (NIS) 

A set of services, generally provided 
by a NIC, to assist users in using the 
network. 

Network News Transfer Protocol 
(NNTP) 

A protocol, defined in RFC 977, for 
the distribution, inquiry, retrieval, and 
posting of news articles. 

node 

An addressable device attached to a 
computer network. See also: host, 
router. 


Open Systems Interconnection (OSI) 

A suite of protocols, designed by ISO 
committees, to be the international 
standard computer network 
architecture. 

OSI Reference Model 

A seven-layer structure designed to 
describe computer network 
architectures and the way that data 
passes through them. This model was 
developed by the ISO in 1978 to 
clearly define the interfaces in 
multivendor networks and provide 
users of those networks with 
conceptual guidelines in the 
construction of such networks. 

packet 

The unit of data sent across a network. 
"Packet" is a generic term used to 
describe a unit of data at all levels of 
the protocol stack, but it is most 
correctly used to describe application 
data units. See also datagram. 

Packet InterNet Groper (PING) 

A program used to test reachability of 
destinations by sending them an ICMP 
echo request and waiting for a reply. 
The term is used as a verb: "Ping host 
X to see if it is up!" 

Point-to-Point Protocol (PPP) 

The Point-to-Point Protocol, defined in 
RFC 1171, provides a method for 
transmitting packets over serial point- 
to-point links. 

port 

A port is a transport layer 
demultiplexing value. Each application 
has a unique port number associated 
with it. See also Transmission Control 
Protocol. 

postmaster 

The person responsible for taking care 
of electronic mail problems, answering 
queries about users, and other related 
work at a site. 
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protocol 

A formal description of message 
formats and the rules two computers 
must follow to exchange those 
messages. Protocols can describe low- 
level details of machine-to-machine 
interfaces (e.g., the order in which bits 
and bytes are sent across a wire) or 
high-level exchanges between 
allocation programs (e.g., the way in 
which two programs transfer a file 
across the Internet). 

protocol stack 

A layered set of protocols that work 
together to provide a set of network 
functions. 

queue 

A backup of packets awaiting 
processing. 

remote login 

Logging in on a remote computer, 
using a protocol over a computer 
network, as though locally attached. 

Remote Procedure Call (RPC) 

An easy and popular paradigm for 
implementing the client-server model 
of distributed computing. In general, a 
request is sent to a remote system to 
execute a designated procedure, using 
arguments supplied, and the result 
returned to the caller. There are many 
variations and subtleties in various 
implementations, resulting in a variety 
of different (incompatible) RPC 
protocols. 

Request For Comments (RFC) 

The document series, begun in 1969, 
that describes the Internet suite of 
protocols and related experiments. Not 
all (in fact very few) RFCs describe 
Internet standards, but all Internet 
standards are written as RFCs. The 
RFC series of documents is unusual in 
that the proposed protocols are 
forwarded by the Internet research and 
development community, acting on 
their own behalf, as opposed to the 
formally reviewed and standardized 
protocols that are promoted by 


organizations such as CCl’lT and 
ANSI. 

route 

The path that network traffic takes 
from its source to its destination. Also, 
a possible path from a given host to 
another host or destination. 

router 

A device that forwards traffic between 
networks. The forwarding decision is 
based on network layer information 
and routing tables, often constructed 
by routing protocols. 

routing 

The process of selecting the correct 
interface and next hop for a packet 
being forwarded. 

Serial Line IP (SLIP) 

A protocol used to run IP over serial 
lines, such as telephone circuits or RS- 
232 cables, interconnecting two 
systems. SLIP is defined in RFC 1055. 

server 

A provider of resources (e.g., file 
servers and name servers). 

Simple Mail Transfer Protocol (SMTP) 

A protocol, defined in STD 10, RFC 
821, used to transfer electronic mail 
between computers. It is a server-to- 
server protocol, so other protocols are 
used to access the messages. 

SUP 

See Serial Line IP. 

snail mail 

A pejorative term referring to the U.S. 
Postal Service. 

TCP/IP Protocol Suite 

Transmission Control Protocol over 
Internet Protocol. This is a common 
shorthand that refers to the suite of 
transport and application protocols that 
runs over IP. 
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Telnet 

Telnet is the Internet standard protocol 
for remote terminal connection service. 
It is defined in STD 8, RFC 854 and 
extended with options by many other 
RFCs. 

Transmission Control Protocol (TCP) 

An Internet Standard transport layer 
protocol defined in STD 7, RFC 793. It 
is connection-oriented and stream- 
oriented, as opposed to UDP. 

Usenet 

A collection of thousands of topically 
named newsgroups, the computers that 
run the protocols, and the people who 
read and submit Usenet news. Not all 
Internet hosts subscribe to Usenet and 
not all Usenet hosts are on the Internet. 

virtual circuit 

A network service that provides 
connection-oriented service regardless 
of the underlying network structure. 

white pages 

The Internet supports several databases 
that contain basic information about 
users, such as email addresses, 
telephone numbers, and postal 
addresses. These databases can be 
searched to get information about 
particular individuals. Because they 
serve a function akin to the telephone 
book, these databases are often 
referred to as "white pages". 

WHOIS 

An Internet program that allows users 
to query a database of people and other 
Internet entities, such as domains, 
networks, and hosts, kept at the DDN 
NIC. The information for people 
shows a person's company name. 


address, phone number, and email 
address. 

Wide Area Information Servers (WAIS) 

A distributed information service that 
offers simple natural language input, 
indexed searching for fast retrieval, 
and a "relevance feedback" mechanism 
that allows the results of initial 
searches to influence future searches. 
Public domain implementations are 
available. 

Wide Area Network (WAN) 

A network, usually constructed with 
serial lines, which covers a large 
geographic area. 

World Wide Web (WWW or W3) 

A hypertext-based, distributed 
information system created by 
researchers at CERN in Switzerland. 
Users may create, edit, or browse 
hypertext documents. The clients and 
servers are freely available. 

X 

X is the name for TCP/IP based 
network-oriented window systems. 
Network window systems allow a 
program to use a display on a different 
computer. The most widely - 
implemented window system is XI 1, a 
component of MIT's Project Athena. 

X.400 

The CCITT and ISO standard for 
electronic mail. It is widely used in 
Europe and Canada. 

X.500 

The CCITT and ISO standard for 
electronic directory services. See also 
white pages, Knowbot, WHOIS. 
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